This draft now includes a concrete TypeScript prototype in @x402/extensions/operation-binding, not just the spec file.

Included in the prototype:

• deterministic logical-input + operationDigest utilities
• JWS / EIP-712 receipt creation and verification helpers
• resource-server declaration helpers for 402 Payment Required
• targeted tests

Validation run locally:

• pnpm --dir typescript --filter @x402/extensions test -- operation-binding.test.ts
• pnpm --dir typescript --filter @x402/extensions build

If this is the right first-step shape, I can keep iterating from here rather than expanding the scope further.

Direction looks right to me — keeping it as a companion extension so receipt format churn doesn't cascade is the sane call.

One question on scope: the v1 receipt is resource-server-signed, which works for any scheme. But some schemes can carry the binding natively — e.g. BOLT11 description_hash can commit directly to the operationDigest, which would give you a cryptographic tie between settlement and operation without needing a separate server signature. Is that a case you'd expect to handle as a future receipt.format value ("lightning-desc-hash" or similar), or is it explicitly out of scope because it muddies the boundary with scheme-level semantics?

Not asking you to solve it here, just trying to understand whether the v1 shape would let that plug in later or whether it'd need its own extension.

Ran the TS prototype on this branch against rfc8785 (pypi) on a handful of vectors. 6 of 8 match, 2 diverge, and both come back to one bug.

The canonicalize the prototype pulls from offer-receipt/signing.ts escapes every C0 control char as \uXXXX. RFC 8785 §3.2.2.2 mandates short forms for \b \f \n \r \t, so any bound string containing those hashes differently between SDKs.

Concrete: body {"query":"line1\nline2","limit":1} under the /search binding from Example B.

• TS prototype emits "query":"line1\u000aline2" → b5f30ef114cc2426389ccd9b0780503425bf4c961b630b78e3286531a8717819
• RFC 8785 emits "query":"line1\nline2" → 5caac7f75db73ddc5c662458aec0f25a58f50358c68c12a17cb7925f43291223

Same story with \t. Since the spec already requires "RFC 8785 exactly, not a JCS-like variant," this reads as a prototype bug rather than a spec ambiguity. Fix is five lines in serializeString (emit short forms for those five chars) or swap to a maintained JCS library.

Test vectors

While both impls were running, pinned 8 vectors against the two example bindings (rfc8785-jcs + sha-256). V1-V3 and V6-V8 agree between the two implementations; V4 and V5 diverge per the bug above.

WEATHER = { resourceUrl: "https://api.example.com/weather/SF", method: "GET",
            pathTemplate: "/weather/:city", operationId: "weather.getCurrent",
            policyVersion: "2026-04-04",
            bindPathParams: true, bindQuery: true, bindBody: false }

SEARCH  = { resourceUrl: "https://api.example.com/search", method: "POST",
            pathTemplate: "/search", operationId: "search.run",
            policyVersion: "2026-04-04",
            bindPathParams: false, bindQuery: false, bindBody: true }

Would be worth pinning a subset of these in the spec as a Test Vectors appendix — independent SDK authors get a bit-for-bit target to verify against, which is the cheapest insurance against drift.

One more number-related thing

rfc8785 (Python) refuses to serialize integers outside ±(2^53−1), because RFC 8785 defers number formatting to ECMAScript Number.prototype.toString which can't represent larger ints without precision loss. Spec currently says body MAY be any JSON value. Probably worth a normative note that bound numbers MUST be within the JS safe-integer range (or represented as strings) — otherwise strict-JCS SDKs in Python/Rust/Go will throw where JS silently drops precision on 2^53 and up.

Can send a small PR against this branch with the escape fix plus regression tests for \n and \t if that's useful.

Addressed the RFC 8785 escaping bug in the shared canonicalizer.

What changed:

• serializeString in offer-receipt/signing.ts now emits the required short escapes for \b, \f, \n, \r, and \t
• added canonicalization regression coverage in offer-receipt.test.ts
• added exact operation-binding digest vectors for the newline and tab cases, plus a bindBody=false vector, in operation-binding.test.ts

Ran locally:

• pnpm --dir typescript --filter @x402/extensions test -- offer-receipt.test.ts operation-binding.test.ts
• pnpm --dir typescript --filter @x402/extensions build

This is on the branch now in 34bab63f.

The operation-binding extension fills the gap between payment and execution cleanly. The operationDigest approach — RFC 8785 canonicalization, SHA-256 digest, deterministic binding — is exactly the right primitive for that layer.

One composition point worth flagging for the spec: the operation-binding receipt answers "was this exact validated operation paid for?" but doesn't address what comes after execution — whether the delivery matched the specification.

SAR (Settlement Attestation Receipt, #1195) is designed to fill that slot. It operates post-execution and produces a signed delivery proof using the same verification profile: RFC 8785 canonicalization, SHA-256 digest derivation, Ed25519 signatures, kid-indexed key discovery. The signed core is intentionally narrow so it composes with operation-binding without coupling envelope semantics.

The full stack would then be:

operationDigest (payment bound to exact operation) → execution → SAR (delivery bound to spec) → reputation signal

On the RFC 8785 escaping issue Bortlesboat identified — SAR's canonicalization implementation uses correct short-form escapes for \b \f \n \r \t per §3.2.2.2. The sar-sdk fixture suite includes vectors covering the \n and \t cases (V4 and V5 in Bortlesboat's table). Happy to share those vectors if useful for cross-validation.

For the shared canonicalization test vector appendix Bortlesboat proposed — aligning SAR fixtures with the operation-binding vector set would give independent implementers a single target to validate both layers against.

@phdargen looping you in for a maintainer read here.

@Bortlesboat's feedback makes me think the companion-extension / first-slice approach is directionally right. Since then this branch has also incorporated the RFC 8785 escaping fix, pinned digest regression vectors, and a small HTTP-flow integration test around operation-binding.

Is this aligned with where you want operation-binding to head? If yes, would you want this merged as the initial prototype and iterate follow-up spec/runtime work in separate PRs, or would you prefer it narrowed or split further before merge?

@Bortlesboat since you’ve already been the main technical reviewer on this thread: with the RFC 8785 escape fix, pinned digest vectors, and the small HTTP-flow integration coverage now on the branch, does this look like the right initial prototype to merge and iterate on in follow-up PRs, or would you prefer it narrowed or split further first?

Escape fix looks correct, vectors match. This is the right shape to merge and iterate.

Only thing I'd track for a follow-up is a Test Vectors appendix in the spec doc itself the TS test suite has them pinned, but SDK authors in other languages will want a bit-for-bit target without having to dig through the TypeScript.

Merge it.

Thanks, that’s very helpful, @Bortlesboat. I’ll keep the Test Vectors appendix as follow-up work so this PR stays narrow. At this point the branch looks stable and the remaining GitHub blocker appears to be a formal approving review from someone with merge rights.

@phdargen @CarsonRoscoe could you take a look at this when you have a moment?

Given @Bortlesboat's review that this is the right first shape to merge and iterate on, I’d mainly like to confirm whether this is aligned with the direction you want operation-binding to head. If yes, I’m happy to keep the Test Vectors appendix and any broader follow-up work in separate PRs.